<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => 'Removing wrapper classes',
	'body' => <<<END
<p>
	I have decided to not only halt progress on my wrapper classes, but to backtrack.
	Simply put, I do not know which functions are worth wrapping in many cases, as I do not know which functions are even worth using.
	I do not need include.d to be cluttered with junk code.
	With that in mind, I am removing any wrapper class that I have never actually used, ass well as my dir wrapper class, which I feel is made obsolete by the built-in <code>\\scandir()</code> function.
</p>
<p>
	I did not have much time this morning before leaving for Springfield, but I did start putting together a function to help me debug include.d.
	All the function really did was load all of include.d&apos;s functions, classes, and constants, which meant that any syntax errors would become immediately visible.
	However, on the way to Springfield, I decided to put together a battery of tests for the actual output of these functions and classes.
	Soon after, I decided that my initial function was kind of arbitrary as a function, and really belonged as part of the test code, so I downgraded my plans for the function itself.
	It would instead be just a set of loops in the test code and it would rely on a constant within include.d to know where include.d was so it could be recursed.
	By adding <code>const _DIR_ = __DIR__;</code> to include.d&apos;s constants file, I would have a way to tell the test suite where include.d&apos;s files were.
	By the end of the day though, I had realized that the test suite did not need include.d to be modified in any way.
	<code>stream_resolve_include_path(&apos;st/y&apos;)</code> would tell my test suite exactly where to find my functions and classes so that they all can be loaded.
	I feel that this is the cleanest way to make it work, as it does not rely on adding stupid hacks to include.d.
	I will of course still add individual test cases for each function and class, but this will mean that I will not have to remember to individually <code>require()</code> each of my functions.
</p>
<p>
	We did not get as much work done in Springfield as we wanted to, nor are we ready to rent that storage unit.
	Still, the planning that i was able to make for my test suite while working made the day worthwhile for me.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
END
);
